Create Active Directory Service Accounts for Keyfactor Command

The user who runs the Keyfactor Command installation must have local administrator permissions on the Keyfactor Command server(s) and must be granted permissions in SQL if Windows authentication for SQL will be used during the installation (see Grant Permissions in SQL). You can either grant these permissions to an existing user or you can create a Keyfactor Command installer account and grant the appropriate permissions to this account.

Additionally, the user installing Keyfactor Command must have the SeBackupPrivilege and SeRestorePrivilege rights on the Keyfactor Command server. Normally, administrators are granted these permissions by default, but you should confirm the permissions prior to starting the install. These permissions can be set through Group Policy or Local Security Policy, and can be found under “Local Policies\User Rights Assignment” as “Back up files and directories” and “Restore files and directories”.

For more information on this from Microsoft, see:

The Keyfactor Command Service (a.k.a. the timer service) runs on the Keyfactor Command services server. It synchronizes certificates to the SQL database and initiates notification and reporting tasks. This service runs in the context of an Active Directory Service account.

The user with this role will be granted permission on each of the SQL schemas (dbo, ssl, ssh, cms_agents, etc.) and permission on the encryption certificate in SQL through the keyfactor_db_role which is created during configuration.

The user with this role must have the “Log on as a service” right on the Keyfactor Command server. Normally, this permission is granted automatically as part of the installation process. You can confirm the permissions through Group Policy or Local Security Policy in “Local Policies\User Rights Assignment”. Validate that the user associated with the Keyfactor Command Service has been added to “Log on as a service” directly or indirectly (via group membership).

The user with this role needs to be able to create log files and write to them. During installation, this permission is granted by granting “Create files / write data” and “Create folders / append data” permissions on the log directory (C:\Keyfactor\logs) to the local users group on the assumption that the local users group will contain either “NT AUTHORITY\authenticated users” or “DOMAIN\Domain Users” and that the service account user will be granted permissions via at least one of these. If this is not the case, permissions for the service account user will need to be granted manually to the log directory.

The user with this role needs to be granted permissions on any certificate authorities from which certificates will be synchronized. Additional certificate authority A certificate authority (CA) is an entity that issues digital certificates. Within Keyfactor Command, a CA may be a Microsoft CA or a Keyfactor gateway to a cloud-based or remote CA. permission may be needed depending on the features that will be used. For more information, see Grant the Keyfactor Command Users and Service Account(s) Permissions on the CAs.

The Keyfactor Command Management Portal uses an application pool under IIS to operate. This application pool runs in the context of an Active Directory service account.

The user with this role will be granted permission on each of the SQL schemas (dbo, ssl, ssh, cms_agents, etc.) and permission on the encryption certificate in SQL through the keyfactor_db_role which is created during configuration.

The user with this role must have the “Log on as a batch job” and “Impersonate a client after authentication” rights on the Keyfactor Command server. In a typical IIS installation, these rights are granted to the IIS_IUSRS group and the user running any application pool created in IIS inherits these rights without being added to the IIS_IUSRS group. For more information about the IIS_IUSRS group, see:

You can confirm the permissions or set them manually for the application pool user through Group Policy or Local Security Policy in “Local Policies\User Rights Assignment”. Validate that either the IIS_IUSRS group or the user associated with the Keyfactor Command application pool has been added to “Log on as a batch job” and “Impersonate a client after authentication” directly or indirectly (via group membership).

The user with this role needs to be able to create log files and write to them. During installation, this permission is granted by granting “Create files / write data” and “Create folders / append data” permissions on the log directory (C:\Keyfactor\logs) to the local users group on the assumption that the local users group will contain either “NT AUTHORITY\authenticated users” or “DOMAIN\Domain Users” and that the service account user will be granted permissions via at least one of these. If this is not the case, permissions for the service account user will need to be granted manually to the log directory.

The user with this role needs to be granted permissions on any certificate authorities from which certificates will be synchronized. Additional certificate authority permission may be needed depending on the features that will be used. For more information, see Grant the Keyfactor Command Users and Service Account(s) Permissions on the CAs.

If Basic authentication will be used to access the Keyfactor Command Management Portal, the Logi Analytics Platform uses a service account to allow Logi to connect to Keyfactor Command via the Keyfactor API A set of functions to allow creation of applications. Keyfactor offers the Keyfactor API, which allows third-party software to integrate with the advanced certificate enrollment and management features of Keyfactor Command. to display the dashboard information. This service account is not required if integrated Windows authentication will be used for the Management Portal. The Keyfactor Command analytics application for dashboard and reporting uses an application pool under IIS to operate. This application pool runs in the context of an Active Directory service account. This role is collocated with the Management Portal; a separate service account for this role is not needed as a single application pool will be used for both.

The Keyfactor Command Orchestrators API IIS application accepts connections from Keyfactor Command orchestrators and uses an application pool under IIS to operate. This application pool runs in the context of an Active Directory service account. If this role will be installed on the server hosting the Keyfactor Command Management Portal role, a separate service account for this role is not needed as a single application pool will be used for both.

The Keyfactor Command Keyfactor API uses an application pool under IIS to operate. This application pool runs in the context of an Active Directory service account. The Keyfactor API is an integral part of Keyfactor Command and is not an optional installation. The Keyfactor API can be configured to support custom applications. If the Keyfactor Command Keyfactor API role will be installed on the server hosting the Keyfactor Command Management Portal role, a separate service account for this role is not needed as a single application pool will be used for both.

The Keyfactor Command Classic API (the classic or legacy API) uses an application pool under IIS to operate. This application pool runs in the context of an Active Directory service account. The Keyfactor Command Classic API may have been configured to support custom applications in previous versions of Keyfactor Command. If the Keyfactor Command Classic API role will be installed on the server hosting the Keyfactor Command Management Portal role, a separate service account for this role is not needed as a single application pool will be used for both.

Keyfactor Command supports synchronization of certificates and certificate enrollment Certificate enrollment refers to the process by which a user requests a digital certificate. The user must submit the request to a certificate authority (CA). from EJBCA certificate authorities by configuring a client certificate issued from the EJBCA CA A certificate authority (CA) is an entity that issues digital certificates. Within Keyfactor Command, a CA may be a Microsoft CA or a Keyfactor gateway to a cloud-based or remote CA. on the CA record in the Management Portal. This client certificate needs to be associated with an end entity in EJBCA that can be assigned sufficient permissions to perform all necessary CA tasks from Keyfactor Command.

Keyfactor Command supports synchronization of certificates and certificate enrollment from Microsoft certificate authorities in remote forests (forests other than the forest An Active Directory forest (AD forest) is the top most logical container in an Active Directory configuration that contains domains, and objects such as users and computers. in which Keyfactor Command is installed which are not in a two-way trust with the Keyfactor Command forest) by configuring a service account from the forest in which the CA resides on the CA record in the Management Portal. All communication to retrieve existing certificates, enroll for new certificates, revoke certificates, and recover certificate keys from the remote CA is done in the context of this service account. Explicit credentials for remote CA access is configured in the Keyfactor Command Management Portal after installation is complete rather than in the configuration wizard.